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(54) Managing file access via a designated storage area 



(57) The present invention relates to techniques for 
managing access to digital assets via a designated 
place or its sub-places. The designated place may be a 
file folder, a directory, a local or remote store. The des- 
ignated place is characterized by or associated with a 
securing module that causes all files stored in the des- 
ignated place to have substantially similar security. In 



other words, a file to be secured can be simply dropped 
into the designated place and the securing module is 
configured to take actions to secure the file transparent- 
ly in accordance with the security characteristics of the 
designated place. Likewise, a designated place can be 
set up to unsecure the secured files being deposited in 
the designated place, provided a user of the secured 
files is permitted to do so. 



2CW-1 200 




fO. 2 A 



Printed by Jouve. 75001 PARIS (FR) 



BNSDOCID: <EP, 



1326156A2J > 



1 



EP1 326 156 A2 



2 



Description 

[0001] The present invention relates to the area of 
protecting electronic data in an enterprise environment, 
and more particularly, relates to techniques tor securing 
digital assets via a designated place and method there- 
for. 

[0002] Attacks on e-businesses by hackers might 
grab newspaper headlines, but the costliest crimes, and 
the most difficult ones to prevent, are likely to be com- 
mitted by internal hackers with inside knowledge. Ex- 
amples of the internal hackers may be among departing 
employees and contractors who have acquired exten- 
sive knowledge about an enterprise and could break into 
its internal networks, accessing files and folders con- 
taining information confidential to the enterprise. 
[0003] Many businesses and organizations have 
been looking for effective ways to protect their proprie- 
tary information. Typically, businesses and organiza- 
tions have deployed firewalls, Virtual Private Networks 
(VPNs), and Intrusion Detection Systems (IDS) to pro- 
vide protection. Unfortunately, these various security 
means have been proven insufficient to reliably protect 
proprietary information residing on its internal networks. 
For example : depending on passwords to access sen- 
sitive documents from within often causes security 
breaches when the password of a few characters long 
is leaked or detected. 

[0004] One of the ongoing efforts in protecting the pro- 
prietary information is to use one or more cryptographic 
techniques to secure the sensitive documents. Using an 
encryption process in a cryptographic technique, one 
party can protect the contents of the data from access 
by an unauthorized third party, yet the intended party 
can read the data using a corresponding decryption 
process. The whole point of cryptography is to keep the 
contents of the data or plaintext as secret as possible 
from eavesdroppers. However, the cryptographic ap- 
proaches (e.g., Pretty Good Privacy or PGP) have re- 
vealed some limitations in certain applications. For ex- 
ample, in a collaborative environment in which there are 
multiple users who need to access an encrypted file 
from various locations, the distribution of the keys used 
in the cryptographic approaches become difficult, often 
requiring sophisticated key management. In addition, 
some cryptographic approaches require an explicit en- 
cryption process. For example, a PGP application 
needs to be activated manually to encrypt documents 
to be protected. 

[0005] Therefore, there is a need to provide flexible 
ways to secure and protect digital assets at all times. 
[0006] The present invention is related to processes, 
systems, architectures and software products for pro- 
viding pervasive security to digital assets at all times and 
is particularly suitable in an enterprise environment. To 
provide efficient ways to secure files or unsecure se- 
cured files and manage secured files of different security 
levels, techniques are disclosed herein to designate one 



or more stores to secure various files. The stores can 
be file folders, directories, local or remote storage spac- 
es and are typically managed through a server or a local 
machine if the stores are user-managed. As a result, 
through the respective designated stores, files can be 
secured and secured files can be managed efficiently 
and consistently. In many cases, the operation of secur- 
ing the files via a designated store is transparent to us- 
ers. 

> [0007] According to one aspect of the present inven- 
tion, a designated store is associated with an access 
control module that is configured to perform securing 
operations when a file is deposited into the store. Inher- 
ently, a security template comprising predetermined se- 
curity information is associated with the store. In one 
embodiment, the securing operations include retrieving 
the security information from the template and embed- 
ding the security information in a header that is integrat- 
ed with or attached to the file in an encrypted form. Thus 
the header provides restrictive access to the file. 
[0008] According to another aspect of the present in- 
vention, an access control module is configured to per- 
form unsecuring operations in a designated store. In 
other words : the store is designated to unseal or unse- 
cure a secured file. When a secured file is attempted to 
be converted to a regular or plain file, the secured file 
can be dropped in the store. As a result, all security 
means embedded in the secured file will be removed 
and the data is decrypted back to its original state, pro- 
vided that a user attempting to do so has sufficient priv- 
ilege. 

[0009] According to still another aspect of the present 
invention, when a file is deposited in a store for being 
secured, the access privilege of a user who performs 
the deposition of the file is always preserved, thus to 
prevent the situation in which the user has lost his/her/ 
its ownership (e.g., full access privilege) once the file is 
secured in accordance with the security settings desig- 
nated to the store. If the security settings do not permit 
the user to access files secured in the store, the access 
control module is configured to add an exception for the 
user to the security in the header according to one em- 
bodiment. Such exception is removed once the owner- 
ship changes. 

[0010] According to yet still another aspect of the 
present invention, when a secured file is deposited in a 
store for being secured, "new" security for the resultant 
secured file effects, provided that the user who attempts 
to revise the "old" security in the secured file is privileged 
to do so. Depending on implementation, the old security 
information is overwritten or superseded by the new se- 
curity. When the old security information is superseded 
by the new security information, the old security infor- 
mation is not immediately lost, instead, displaced in a 
temporary place (e.g., a stack). As a result, an "undo" 
mechanism is provided. 

[0011] According to yet still another aspect of the 
present invention, the designated stores are classified 
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into what are called herein system-managed stores and 
user-managed stores. As the name suggests, the sys- 
tem-managed stores are managed by a server machine 
(i.e., a computing device providing centralized access 
management), and the user-managed stores are locally 5 
created in a local machine and managed by a corre- 
sponding individual user. The operations of the user- 
managed stores are similar to those system-managed 
stores except that they can be accessed by the user 
without the user or the local machine being authenticat- 10 
ed with the server machine first, while none of the sys- 
tem-managed stores can be accessed without the user 
or a local machine being authenticated first by the server 
machine. Optionally, branching or child-stores in a des- 
ignated "parent" store may be created or managed to 15 
satisfy certain needs. Regardless the parent store is 
system-managed or user-managed, the security poli- 
cies for the child-stores are generally more restrictive. 
[0012] According to yet still another aspect of the 
present invention, a security change pertaining to a des- 20 
ignated store can be propagated to the designated store 
and secured files, if there are any in the store, by what 
is referred to as a crawling method. In the case in which 
the security change is initiated in a server machine, the 
change is included in a crawler or spider that is released 25 
to a machine hosting the affected store. The spider up- 
dates, in addition to the security template associated 
with the store, each of the secured files automatically. 
As a result, all existing secured files are up to date with 
the security change and ail files that are deposited in the 30 
store are secured in accordance with the updated secu- 
rity template. 

[0013] Depending on implementation and application, 
the present invention may be implemented or employed 
in a client machine and/or a server machine or in a dis- 35 
tributed manner. In one embodiment, the present inven- 
tion is a method for securing files in a store, the method 
comprises associating a security template with the 
store, retrieving the security template when a file is de- 
posited in the store, encrypting the file in accordance 40 
with the security template to produce an encrypted data 
portion, generating a header to include security informa- 
tion from the security template, and integrating the 
header with the encrypted data portion to produce a se- 
cured file. 45 
[0014] In another embodiment, the present invention 
is a method for securing files in a store, the method com- 
prises associating a security template with the store, re- 
trieving the security template when a secured file is de- 
posited in the store by a user, wherein the secured file so 
includes a header and an encrypted data portion, the 
header including embedded security information con- 
trolling restrictive access to the encrypted data portion, 
evaluating the embedded security information from the 
header of the secured file against access privilege of the 55 
user to determine whether the user is permitted to revise 
the embedded security information of the secured file, 
and superseding the embedded security information 



with current security information from the security tem- 
plate after the user is determined to be permitted to re- 
vise the embedded security information of the secured 
file. To provide a possible "undo" operation, the super- 
seding of the embedded security information with the 
current security information comprises preserving the 
embedded security information in a temporary place, 
and replacing the embedded security information in the 
header of the secured file with the current security infor- 
mation, 

[001 5] In still another embodiment, the present inven- 
tion is a method for securing files in a store, the method 
comprises associating a security template with the 
store, retrieving the security template when a secured 
file is deposited in the store by a user wherein the se- 
cured file includes a header and an encrypted data por- 
tion, the header including embedded security informa- 
tion controlling restrictive access to the encrypted data 
portion, evaluating the embedded security information 
from the header of the secured file against access priv- 
ilege of the user to determine whether the user is per- 
mitted to revise the embedded security information of 
the secured file, and after the user is determined to be 
permitted to revise the embedded security information 
of the secured file : evaluating current security informa- 
tion in the template to determine whetherthe user is per- 
mitted to access files in the store, after the user is de- 
termined not to be permitted to access the files in the 
store, adding a special access policy to the security in- 
formation to be included in the header such that the user 
can still access the secured file secured in accordance 
with the security template associated with the store. 
[0016] It can be appreciated by those skilled in the art 
that the above exemplary implementations can also be 
implemented as a system, an apparatus and a software 
product. There are numerous advantageous, benefits, 
and features of providing designated places for securing 
or unsecuring files. One of them is a mechanism, con- 
templated in the present invention, capable of securing 
files efficiently, consistently and transparently to users. 
Another one is that secured digital assets can be more 
effectively managed through respective designated 
places, each having its own predefined access policy. 
[0017] Objects, features, and advantages of the 
present invention will become apparent upon examining 
the following detailed description of an embodiment 
thereof, taken in conjunction with the attached drawings. 
[0018] These and other features, aspects, and advan- 
tages of the present invention will become better under- 
stood with regard to the following description, appended 
claims, and accompanying drawings where: 

FIG. 1 A shows a configuration of employing a des- 
ignated store to secure a plain file according to one 
aspect of the present invention; 
FIG. 1 B shows a configuration of employing a des- 
ignated store to unsecure a secured file according 
to one aspect of the present invention; 
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FIG. 2A shows an access control module managing 
a plurality of stores, each of the stores is for secur- 
ing files in accordance with a different access poli- 
cy; 

FIG. 2B shows an exemplary structure for security s 
information in a security template associate with a 
designated store. 

FIG. 2C shows an example of access rights ex- 
pressed in XACML; 

FIG. 3A shows a process flowchart for securing a 10 
file in a designated store according to one embod- 
iment of the present invention: 
FIG. 3B shows an exemplary data structure of a se- 
cured file produced via a protected store; 
FIG. 3C shows an exemplary header structure of a 15 
secured file according to one embodiment of the 
present invention; 

FIG. 4A shows a process flowchart of securing a file 
that can be plain or secured; 

FIG. 4B illustrates how an existing security informa- 20 
tion is being superseded according to one embod- 
iment of the present invention and may be imple- 
mented as a block in FIG. 4A; 
FIG. 5A shows a basic security system in which the 
present invention may be practised in accordance 25 
with one embodiment thereof; 
FIG. 5B shows an exemplary graphic user interface 
that can facilitate a system operator to create a de- 
sired store or view/modify characteristics of an ex- 
isting store; 30 
FIG. 6A shows a flowchart of a user authentication 
process that may be implemented in a server ma- 
chine; 

FIG. 6B shows an exemplary folder layout accord- 
ing to one aspect of the present invention; 35 
FIG. 6C shows a flowchart of removing security in 
a secured file deposited in a special store; 
FIG. 6D shows sub-stores or child-stores are creat- 
ed under a designated store, 

FIG. 6E shows a process flowchart of creating child- *o 
stores under a parent store according to one em- 
bodiment of the present invention; 
FIG. 7A shows a process flowchart of delivering 
changes pertaining to designated stores; and 
FIG. 73 illustrates that an update patch (e.g., car- 45 
ried in a spider or pushed from a central server) is 
being propagated into an affected store associated 
with a security template and including a secured file. 

[0019] Broadly speaking, the present invention per- so 
tains to techniques for securing digital assets via a des- 
ignated place that may be a file folder, a directory, a local 
or remote store. The designated place is characterized 
by or associated with a securing module that causes all 
files stored in the designated place to have substantially ss 
similar security. In other words, a file to be secured can 
be simply dropped into the designated place and the se- 
curing module is configured to take actions to secure 



the file transparently in accordance with the security 
characteristics of the designated place. Likewise, a des- 
ignated place can be set up to unsecure the secured 
• files being deposited in the designated place, provided 
a user of the secured files has the privilege to do so. 
There are numerous advantageous, benefits, and fea- 
tures of providing designated places for securing or un- 
securing files. One of them is a mechanism, contemplat- 
ed in the present invention, capable of securing files ef- 
ficiently, consistently and transparently to users. Anoth- 
er one is that secured digital assets can be more effec- 
tively managed through respective designated places, 
each having its own predefined access policy. Other ad- 
vantageous, benefits, and features in the present inven- 
tion can be readily appreciated by those skilled in the 
art from the detailed description of the invention provid- 
ed herein. 

[0020] In the following description, numerous specific 
details are set forth in order to provide a thorough un- 
derstanding of the present invention. However, it will be- 
come obvious to those skilled in the art that the present 
invention may be practised without these specific de- 
tails. The description and representation herein are the 
common means used by those experienced or skilled in 
the art to most effectively convey the substance of their 
work to others skilled in the art. In other instances, well- 
known methods, procedures, components, and circuitry 
have not been described in detail to avoid unnecessarily 
obscuring aspects of the present invention. Reference 
herein to "one embodiment" or "an embodiment" means 
that a particular feature, structure, or characteristic de- 
scribed in connection with the embodiment can be in- 
cluded in at least one embodiment of the invention. The 
appearances of the phrase "in one embodiment" in var- 
ious places in the specification are not necessarily all 
referring to the same embodiment, nor are separate or 
alternative embodiments mutually exclusive of other 
embodiments. Further, the order of blocks in process 
flowcharts or diagrams representing one or more em- 
bodiments of the invention do not inherently indicate any 
particular order nor imply any limitations in the invention . 
[0021 ] Embodiments of the present invention are dis- 
cussed herein with reference to FIGS. 1 - 73, in which 
like numerals refer to like parts throughout the several 
views. However, those skilled in the art will readily ap- 
preciate that the detailed description given herein with 
respect to these figures is for explanatory purposes as 
the invention extends beyond these limited embodi- 
ments. 

[0022] Generally, a content created by a creator for 
the purpose of an entity is an intellectual property be- 
longing to the creator or the entity. In an enterprise, any 
kind of information or intellectual property can be con- 
tent, though it is commonly referred to as "information" 
instead of "content". In either case, content or informa- 
tion is independent of its format, it may be in a printout 
or an electronic document. As used herein, content or 
information exists in a type of electronic data that is also 
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referred to as a digital asset or simply a file. A represen- 
tation of a file may include, but not be limited to. various 
types of documents, multimedia files, streaming data, 
dynamic or static data, executable code, images and 
texts. 

[0023] To prevent content in electronic data from un- 
authorized access, the electronic data is typically stored 
in a form that is as close to impossible as possible to 
read without a priori knowledge. Its purpose is to ensure 
privacy by keeping the content hidden from anyone for 
whom it is not intended, even those who have access 
to the electronic data. Example of a priori knowledge 
may include, but not be limited to, a password, a secret 
phrase, biometric information or one or more keys. How- 
ever, on the other end, relying solely upon a priori knowl- 
edge to guard a system or a secured file is not always 
secure. For example, when a password or a secret 
phrase is leaked to or hacked by an intruder the security 
of a system or a secured file can be breached. Likewise, 
using encryption of the electronic data (e.g., PGP) can 
introduce many inconveniences in a collaborative envi- 
ronment. 

[0024] FIG. 1 A shows a configuration 100 according 
to one aspect of the present invention. Configuration 
100 includes a protected store 102 for securing files in 
a convenient, manageable, and consistent manner. De- 
pending on implementation, the store 102 can be a file 
folder, a directory, a remote or local storage space for 
storing and/or securing various types of electronic data 
or files. In other words, the files in store 1 02 are secured 
and will remain secured even if they are moved to other 
locations and can only be accessed by authorized us- 
ers. According to one feature of the store 102, a plain 
file 106 can be secured by simply being deposited into 
the store 1 02. As a result, a secured version 1 08 of the 
plain file 106 is produced. 

[0025] According to one embodiment, the store 1 02 
is inherently associated with an access control manage- 
ment 104 that can be implemented a software module. 
Access control management 1 04 is activated when a file 
is attempted in store 102. As used herein, an "attempt- 
ing" of a file may mean that a file is being deposited into, 
accessed in or removed out of the store 1 02. When the 
file 108 is accessed (e.g., to be opened, printed or at- 
tached to an email), the access control management 
104 is configured to determine if a requestor or user at- 
tempting the file 108 has sufficient access privilege to 
do so before the file is released. Unless specifically stat- 
ed differently, a user or a requestor is interchangeably 
used herein to identify a human user, a software agent, 
or a group of users and/or software agents. Besides a 
human user who needs to access a secured document, 
a software application or agent sometimes needs to ac- 
cess the secured document in order to proceed forward. 
[0026] FIG. 1 B shows a configuration 110 according 
to another aspect of the present invention. Configuration 
110 includes a "special" store 112 for unsecuring any 
secured files that are being deposited therein. In order 



words, a secured file 1 1 6 can become a regular or plain 
file 118 after it is dropped into the store 112. Similar to 
the store 102, the store 112 is inherently associated with 
an access control management 110 that is configured 

5 to strip off any security means embedded in a secured 
file being deposited therein, provided that the user of the 
secured file has the privilege to do so. 
[0027] FIG. 2A shows an access control module 202 
managing a plurality of stores 206-1, 206-2, ... 206-n. 

10 Each of the stores 206 is for securing files in accordance 
with a different access policy. For example, the store 
206-1 is configured for an engineering group such that 
every member in the group may access the files in the 
store 206-1 while the store 206-2 is configured for a mar- 

15 keting group such that every member in the marketing 
group may access the files in the store 206-2. Likewise, 
the store 206-n may be configured to allow some in one 
group and others in another group to access files se- 
cured therein. In any case, depending on implementa- 

20 tion, various access security needs can be achieved 
through one or more of the stores 206. 
[0028] Under the management of access control 
module 202 : each of stores 206 is associated with one 
of the security templates 204. A security template, as 

25 will be further illustrated and explained below, contains 
essential security information and various parameters 
designated for a folder and may be in one or more files 
or in one or more system policies. Depending on imple- 
mentation, the security information contains one or 

30 more access policies (e.g., who, how, when or where 
the secured files in the store can be accessed), cipher 
information and other security related information. FIG. 
2B shows an exemplary structure for the security infor- 
mation 220 in a security template 218. The security in- 

35 formation 220 includes cipher information 222, access 
policy 224 and store designation information 226. In 
general, the cipher information 222 indicates what ci- 
pher scheme (e.g., Data Encryption Standard algorithm, 
Btowfish block cipher and Twofish cipher) is employed 

40 to encrypt the original plain file and, perhaps, how the 
plain file is encrypted. Access policy 224 is a set of ac- 
cess rules providing restrictive access to a key(s) and/ 
orthe encrypted data. The store designation information 
226 indicates how the store is designated, for example, 

45 a store created and managed by a server versus a store 
created by a user for local use. It can be appreciated by 
those skilled in the art that the security template 21 8 may 
be designed differently depending on an actual deploy- 
ment of a security system. Various types of information 

50 can be added in a security template that includes at least 
one access policy in the context of the present invention. 
[0029] In general, a security template is stored in a 
tamper-proof storage place in a client machine (e.g., a 
desktop computer, a laptop computer or any computing 

55 device) and becomes readily available after the user of 
the client machine is authenticated. For example, the 
store 206-1 is associated with the template 204-1 while 
the store 206-n is associated with the security template 
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204-n. In operations, when a plain file is deposited in the 
store 206-n, the corresponding security template 204-n 
is retrieved and a part or all of the corresponding security 
template 204-n is included in a header that is subse- 
quently attached to or integrated with an encrypted ver- 
sion of the file, wherein the security information in the 
header provides restrictive access to the encrypted ver- 
sion of the file. 

[0030] A portion of the security information in a secu- 
rity template is, or can generate, an access policy or pol- 
icies. A policy, possibly parameterized, is a set of rights 
determining whether an access request from a reques- 
tor is to be granted. According to one embodiment, the 
rights can be expressed in a descriptive language (un- 
derstandable literally), such as a markup language and 
a text file. Examples of the markup language may in- 
clude, but not be limited to, HTML, XML, WML. and 
SGML. In a preferred embodiment, the markup lan- 
guage is Extensible Access Control Markup Language 
(XACML) that is essentially an XML specification for ex- 
pressing policies for information access. In general, 
XACML can address fine grained control of authorized 
activities, the effect of characteristics of the access re- 
questor, the protocol over which the request is made, 
authorization based on classes of activities, and content 
introspection (i.e., authorization based on both the re- 
questor and attribute values within the target where the 
values of the attributes may not be known to the policy 
writer). In addition, XACML can suggest a policy author- 
ization model to guide implementers of the authorization 
mechanism. 

[0031] A simplified example 230 of access rights ex- 
pressed in a language similar to XACML is provided in 
FIG. 2C. The literal meaning of the above example may 
be interpreted as "a secured file called customerlist.doc 
created by ACCTG (accounting group), can be VIE Wed 
and PRINTed by MKTG (marketing group), on the con- 
dition that this document can be accessed over secured 
HTTP, accessed before 5:00 PM in the day, before Au- 
gust 3, 2002." 

[0032] FIG. 3A shows a process flowchart 300 for se- 
curing a file in a store according to one embodiment of 
the present invention. The file can be any type of elec- 
tronic data (e.g. , xyz.doc and abc.pdf) and the store may 
correspond to the store 1 02 of FIG. 1 A. At 302, the proc- 
ess 302 determines if there is any file being deposited 
in the store and proceeds once it is detected that a file 
has been placed into the store. At 304, a security tem- 
plate associated with the store is retrieved. The security 
template may be obtained directly from a storage space, 
recovered or decrypted from a secured version thereof 
or generated in real time in accordance with the settings 
for the store. 

[0033] Once the security template is readily available, 
a header is generated for the file at 306. In essence, the i 
header includes a portion or whole of the security tem- 
plate. At 308, the deposited file is encrypted in accord- 
ance with a cipher scheme in the security template. The 



header is then attached to or integrated to the file at 31 0 
such that any attempt to the file is now regulated by the 
security information in the header. Subsequently, a se- 
cured file is produced at 312 and can only be accessed 

5 by authorized users. 

[0034] According to one embodiment, the plain file be- 
ing deposited in the store is first encrypted in accord- 
ance with a cipher scheme in the security template. A 
cipher key (e.g., a decryption key) is then stored in and 

™ guarded by the access rules in the header, and at least 
part of the header is encrypted by a separate key. When 
a request from a user to access the secured file, the ac- 
cess rules in the security information of the header will 
be measured against the access privilege of the user. If 

'5 the access privilege of the user is met within the access 
policy, the access request is granted and the user can 
thus access the secured file, otherwise, the access is 
denied. U. S. Patent Application No.: 10/074,804 pro- 
vides an additional description of accessing a secured 

20 file. 

[0035] FIG. 3B shows an exemplary data structure 
320 of a secured file produced via a protected store. The 
data structure 320 includes two portions: a header (or 
header portion) 322 and encrypted data (or an encrypt- 
25 ed data portion) 324. The header 322 can be generated 
in accordance with a security template associated with 
the store and thus provides restrictive access to the data 
portion 324 that is an encrypted version of a plain file. 
Optionally, the data structure 320 may also include an 
30 error-checking portion 325 that stores one or more error- 
checking codes, for example, a separate error-checking 
code for each block of encrypted data portion 324. 
These error-checking codes may also be associated 
with a Cyclical Redundancy Check (CRC) for the header 
322 and/or the encrypted data portion 324. The header 
322 includes a flag bit or signature 327 and security in- 
formation 326 that is in accordance with the security 
template for the store. According to one embodiment, 
the security information 326 is encrypted and can be de- 
w crypted with a user key associated with an authenticated 
user. 

[0036] The security information 326 can vary depend- 
ing upon implementation. However, as shown in FIG. 
3B : the security information 326 includes a user identi- 

5 fier (ID) 328, rules (access rules) 329, a file key 330 and 
other 331. Although multiple user identifiers may be 
used, a user identifier 328 is used to identify a user or 
a group of users that are permitted to access the se- 
cured file 320. The access rules 329 provide restrictive 

o access to the encrypted data portion 324. The file key 
330 is a cipher key that, once obtained, can be used to 
decrypt the encrypted data portion 324 and thus, in gen- 
eral, is protected. In one implementation of the structure 
320, the file key 330 is encrypted in conjunction with the 

* access rules 329. In another implementation of the 
structure 320, the file key 330 is double encrypted with 
a protection key and further protected by the access 
rules 329. The other 331 is an additional space for other 
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information to be stored within the security information 
326. For example, the other information 331 may be 
used to include other information facilitating secure ac- 
cess to the secured file, such as version number or au- 
thor identifier. U. S. Patent Application No.: 10/074,804 
provides a description of an exemplary format of a se- 
cured file in accordance with the structure 320. 
[0037] FIG. 3C shows an exemplary header structure 
350 of a secured file according to one embodiment of 
the present invention. In general, a header of a secured 
file is a point of entry to the secured file. The header 
structure 350 includes various security information to 
ensure that only an authorized user with sufficient ac- 
cess privilege can access the encrypted data in the se- 
cured file. The security information is cryptographically 
protected or secured. In one embodiment, a good part 
of the header or the security information therein is pro- 
tected by a Message Authentication Code (MAC) that 
can detect any tampering with the header by an unau- 
thorized user without a valid key or CRC 31 6 of FIG. 3A. 
[0038] One portion in the header structure 350 is re- 
ferred to as a key block list 352 that may contain one or 
more key blocks. A key block 354 contains an encrypted 
protection key that is sometimes referred to as docu- 
ment/file-encryption-key key, namely a key to the file 
key. To ensure that the protection key is indeed protect- 
ed, it is encrypted and can only be retrieved (e.g., de- 
crypted) by a designated entity. For example, a secured 
file is created by a member of engineering group and 
permitted for full access by every member in the engi- 
neering group. The same secured file meanwhile is also 
permitted for limited access (e.g., only read and print) 
by every member in the marketing group. Accordingly, 
the key block list 352 may include two key blocks, one 
for the engineering group and the otherforthe marketing 
group. In other words : each of the two key blocks has 
an encrypted protection key that can be only accessed 
by a member of the corresponding group (via a group 
or individual private key). 

[0039] The key block version value 356 provides nec- 
essary details of the encryption algorithm used to pro- 
tect the protection key 340. In one embodiment, the 
RSA-OAEP (RSA - Optimal Asymmetric Encryption 
Padding) which is a public-key encryption scheme com- 
bining the RSA algorithm with the OAEP method is 
used. In particular, the uuid of the key pair 358 identifies 
a certificate and a private key (the details thereof are 
not shown) that are used to decrypt this value. In addi- 
tion, attributes of the key pair, such as key length or 
versions , are also included to facilitate the protection of 
the protection key 340. 

[0040] The block 342 of the header structure 350 in- 
cludes at least three segments 344, 346 and 348. The 
segment 344 includes an encrypted file key that must 
be retrieved in order to decrypt the encrypted data por- 
tion. The segment 346 includes security level informa- 
tion to indicate what security level the secured file is at, 
for example, "top secret", "secret", "confidential" or "un- 



classified" or "none". The segment 348 includes infor- 
mation about the size of the encryption block for the en- 
crypted data portion in the secured file. According to one 
embodiment, this is a multiple of the algorithm encryp- 

5 tion block size. The encrypted data portion is created by 
encryption with a symmetric key that is called the doc- 
ument/file-encryption-key or file key herein. 
[0041] There is another portion 360 of the header 
structure 350 that is encrypted by a user or group key. 

10 The portion 360 (the details thereof are not shown) con- 
tains essentially the access rules embedded with the se- 
cured file to govern who/where the secured file can be 
accessed. Various conditions of accessing the file can 
be placed or realized in the access rules. 

is [0042] In an alternative data structure for a secured 
file, the header can include at least one pointer which 
points to a remote data structure stored in a storage 
space. The remote data structure can store some or all 
of the security information, thereby shortening the size 

20 of the header and improving manageability of security 
information. The storage device is typically a local stor- 
age device. In other words, the alternative data structure 
and the remote data structure are typically stored on a 
common machine (e.g.. desktop or portable computer). 

25 Additional details on the alternative data structure can 
be found in U.S. Application No. 10/132,712, filed April 
26, 2002, and entitled "METHOD AND SYSTEM FOR 
PROVIDING MANAGEABILITY TO SECURITY IN- 
FORMATION FOR SECURED ITEMS," which is hereby 

30 incorporated herein by reference. 

[0043] One advantage of setting up a protected place 
or a designated store is to provide a securing mecha- 
nism for users to create secured files without individually 
specifying as to who/how/when/where secured files can 

35 be accessed. However, in some situations, an author- 
ized user with sufficient access privilege needs to revise 
the access policy in a secured file. For example, an en- 
gineering document originally created for access by 
members of an engineering group needs now to be ac- 

40 cessed by members of a marketing team. According to 
one aspect of the present invention, when a secured file 
is deposited in a store having a different security tem- 
plate, the existing security information in the secured file 
will be superseded but not immediately overwritten. In 

^5 other words, the displaced "old" security information is 
still preserved somewhere, thus providing the ability to 
"undo" the operation if desired. 

[0044] FIG. 4A shows a process flowchart 400 of se- 
curing a file that can be plain or secured. At 402, the 

so process 400 determines whether a file is being depos- 
ited in a store. Once it is detected that a file is deposited 
in the store, the process 400 proceeds. The process 400 
retrieves a security template for the store at 404. Since 
a file being deposited can be either plain or secured, the 

55 security nature of the file is determined at 406. When it 
is determined that the file is plain, namely it is non-se- 
cured, the process 400 goes through 408, 41 0, 412 and 
414, each of which is respectively similar to 306, 308, 
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310, and 312 of FIG. 3A, and the description thereof is 
thus omitted and can be referred to the description of 
the same for FIG. 3A. 

[0045] When it is determined that the file is secured, 
which indicates that the file deposited in the store is in 
a format or structure that includes a header while the 
header itself includes necessary security information 
controlling access thereto. To ensure that a user that has 
deposited the file has the privilege to revise the access 
policy of a secured file, the access privilege of the user 
is retrieved at 416. This determination is necessary to 
avoid a situation in which an unauthorized user lessens 
the access policy in a secured file by depositing it into 
a store that the unauthorized user is permitted to ac- 
cess. To facilitate the description of the process 400. it 
is assumed that the user of the file has the privilege to 
revise the current security information (e.g., access pol- 
icy) embedded in the secured file. In general, an access 
privilege of a user is determined when the user logs onto 
a security system, which will be further described below. 
[0046] At 41 8, the security information in the security 
template retrieved at 404 supersedes the current secu- 
rity information. As described above, to provide at least 
one level "undo" operation, the "current" security infor- 
mation that is being superseded is displaced some- 
where but not necessarily deleted immediately. Once 
the new security information is in place, a secured file 
is generated at 41 4 in accordance with the security tem- 
plate associated with the store. 

[0047] FIG. 4B illustrates how an existing security in- 
formation is being superseded according to one embod- 
iment of the present invention and may be implemented 
as 41 8 of FIG. 4A. A secured file 422 is being deposited 
by a user in a store 424. It is assumed that the user has 
the access privilege to revise the security information of 
the secured file 422. For example, a leader of an engi- 
neering team desires to have a marketing team to re- 
view an engineering document that had been only ac- 
cessed by the members of the engineering team. For 
the marketing team to access this engineering docu- 
ment, the access policy of the file must be revised to 
include permitted access from the marketing team. It is 
assumed that the store 424 is indeed set up for access 
from both the engineering and marketing teams. Thus 
a simple deposit of the secured file 422 into the store 
424 will achieve the revision of the access policy origi- 
nally embedded in the secured file 422. 
[0048] To make it possible to undo such revision if de- 
sired, the access control module associated with the 
store 424 is configured to copy the original security in- 
formation 426 into an undo stack or a temporary mem- 
ory space pointed by a pointer that is placed in a stack. 
In either case, the stack 428 operates as a last- in -first- 
out (LIFO) stack. Although the newly secured file 430 
includes the security information in accordance with the 
security template associated with the store 424, the 
"old" security information 426 is preserved. When an 
"undo" operation is performed, the "old" security infor- 



mation 426 is provided and replaces the "new" security 
information in the secured file 430 so as to recover the 
"old" secured file 422 or produce a secured file in ac- 
cordance with the "old" security information. In general, 
5 the LIFO memory is configured into K ievels with the K- 
th level for storing the latest "old" security information, 
wherein K is a finite positive number. When another "old" 
security information is received in the LIFO memory, the 
old" security information is pushed down tc the (K-1 )-th 
10 layer and the K-th layer is used to preserve the 
another "old" security information. Likewise, when the 
content in the K-th layer is called up (i.e., used to replace 
the security information in a secured file), the content in 
the (K-1)-th layer is pushed up to the K-th layer. 

'5 [0049] In any case, regardless how a file (secured or 
plain) is secured in a store, the user who caused the file 
to be so secured is always granted full access to the 
secured file. This feature eliminates a situation in which 
the user accidentally deposited a file into a store that 

20 the user is not permitted to access and thus lost control 
of the file. Accordingly, when such situation happens, a 
separate set of access rules is created in the header to 
guarantee the user full access to the secured file. Gen- 
erally, the separate set of access rules can be deleted 

25 or modified next time the security of the file is revised 
by another user. 

[0050] FIG. 5A shows a basic security system 500 in 
which the present invention may be practised in accord- 
ance with one embodiment thereof. The security system 
30 500 may be employed in an enterprise or inter-enter- 
prise environment. It includes a first server 506 (also re- 
ferred to as a central server) providing centralized ac- 
cess management for the enterprise thus files secured 
in the security system 500 can be controlled for restric- 
ts tive access. To provide the dependability, reliability and 
scalability of the system, one or more second servers 
504 (also referred to as local servers of which one is 
shown) may be employed to provide backup or distrib- 
uted access management for users or client machines 
40 serviced locally. For illustration purpose, there are two 
client machines 501 and 502 being serviced by a local 
server 504. Additional description of FIG. 5A may be 
provided in U. S. Patent Application No.: 10/074, 804. 
[0051 ] In general, there are a plurality of stores in the 
45 security system 500, each of the stores is created and 
used for securing files for one type of security needs and 
typically managed by the central server 502. FIG. 5B 
shows an exemplary graphic user interface 520 that can 
facilitate a system operator to create a desired store or 
50 view/modify characteristics of an existing store. De- 
pending on the purpose of a store to be created, a spe- 
cific name 522 may be provided, for example, "engineer- 
ing" and "sales". As shown, a name "Store X" is entered 
at 522 for a folder to be created. A display 524 shows a 
55 list of users, groups and devices that are being serviced 
in the security system 500 and can be selectively cho- 
sen to be the potential users permitted to access the 
store (e.g., files in Store X). A panel 526 allows the sys- 
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tern operator to determine what access privilege these 
selected users of the store may have. Depending on an 
exact implementation, these selected users may read 
(open) : print, revise or delete the tiles in the store and 
some or all of the users may be able to revise the secu- 5 
rity of the files in the store or create sub-stores (e.g., 
sub-folders or directories) under the store. It should be 
noted that the panel 526 lists only exemplary actions. 
Those skilled in the art can appreciate that other desir- 
able actions or privileges may be provided. 
[0052] After the settings for the folder are satisfied, an 
activation of a button (e.g., "Apply" 528) or "enter" caus- 
es the folder to be created in accordance with the set- 
tings. According to one embodiment, the graphic user 
interface 520 can be accessed from an administration 
interface of a server module which is described in U. S. 
Patent Application No.: 10/074,804. Likewise, all sys- 
tem-managed stores can be viewed in display 530. 
When a particular store in display 530 is selected, the 
display 523 shows the users currently privileged to the 
selected store. In addition, buttons "add" and "delete" 
or like can be used to facilitate the creating/changes of 
the system-managed stores. 

[0053] In general, the parameters or settings of the 
stores are managed in a database maintained in the 
central server 506. To synchronize the stores with the 
client machines and to facilitate all applicable client ma- 
chines to access the stores, the setting of the managed 
stores need to propagate to the applicable client ma- 
chines once they are authenticated. 
[0054] FIG. 6A shows a flowchart of a user authenti- 
cation process 600 that may be implemented in the cen- 
tral server 506 or the local server 504 of FIG. 5A. Typi- 
cally, there are at least two situations that will call upon 
the process 600, a user initially logins onto a networked 
client machine or for first time accesses a secured file. 
When either one of these situations happens, a client 
module in the client machine initiates a request that is 
transmitted to a server providing the access control 
management to start the process 600. 
[0055] At 602, the server awaits the request. Upon re- 
ceiving the request from the client machine, the server 
proceeds at 604 to determine if the user and/or the client 
machine from which the user attempts to access a se- 
cured file have been authenticated. If both have already 
been authenticated, there will be no more authentication 
processing for either of the user or the client machine. 
On the other hand, the authentication process 600 con- 
tinues when the user and/or the client machine have not 
already been authenticated. In one embodiment, the 
server may initiate a secured link with the client machine 
if both the server and the client machine are coupled to 
an open network, such link may be over HTTPS, sup- 
ported through VPN or other means. Alternatively, there 
may be a direct link between the client and the server if 
another authentication means is employed. 
[0056] At 606, the server responds to the received re- 
quest with an authentication response. Depending on 



implementation, such response may be a dialog box to 
be displayed on the screen of the client machine, a com- 
mand or other demand. In any case, the response re- 
quires that credential information be provided by the us- 
er. In general., the credential information may be a set 
of username and password or biometric information of 
the user and must be received from the user at 608 be- 
fore the authentication may proceed forward. 
[0057] At 610, upon receiving the credential informa- 
tion, the server needs to determine if the user is an au- 
thorized one to access any secured files maintained in 
a repository, a local store, the server itself or other de- 
vice accessible over the network. This may involve in a 
match of the received credential with what is previously 
stored in the server. It should be noted that the server 
may be a central server or a local server. Those skilled 
in the art can understand that the description is equally 
applied in either one of the settings. If the match fails, 
namely the user is not authorized, the process 600 goes 
back to the beginning to wait for a new request. In other 
words, the current request to access the secured files 
or login to the system is abandoned. If the match suc- 
ceeds, the user is recognized as being authorized. At 
the same time, the client machine goes to a similar au- 
thentication by, perhaps, an IP address thereof , ora net- 
work card identification therein, or other means that 
uniquely identifies the client machine. 
[0058] With the authentication of the user and/or the 
client machine, the process 600 goes to 612 where the 
user's access privilege is retrieved and activated. De- 
pending on implementation, an activation of the user's 
access privilege may result in downloading of control 
parameters or a file containing the access privilege to 
the client machine, a decryption of a local file containing 
the access privilege, or simply an activation of the user's 
account in a memory space of the server. In any case, 
at this point, the user's access privilege is readily acces- 
sible, thus permitting the userto access the secured files 
from the authenticated client machine. 
[0059] In the context of the present invention, infor- 
mation (e.g., store setting parameters) regarding the 
system-managed stores is downloaded to the client ma- 
chine at 614 such that the user can access some or all 
of the stores managed by the server. According to one 
exemplary embodiment, XML-RPC is used to facilitate 
the communication between a server (e.g., a local serv- 
er or a central server) and a client machine, XML-RPC 
is a simple and portable way to make remote procedure 
calls over HTTP. It can be used with Peri, Java, Python, 
C, C++, PHP and many other programming languages. 
In addition, XML-RPC allows software running on dis- 
parate operating systems, running in different environ- 
ments to make procedure calls over a data network. It 
is remote procedure calling using HTTP as the transport 
and XML as the encoding. XML-RPC is designed to be 
as simple as possible, while allowing complex data 
structures to be transmitted, processed and returned. It 
is understood to those skilled in the art that other com- 
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munication means or protocols are possible given the 
description herein. 

[0060] Essentially, the system-managed stores are 
created by a system administrator or a user with suffi- 
cient access privilege and managed in a server. The se- 
curity for the stores can not be altered by users other 
than the administrator or a user with sufficient access 
privilege. In contrast to the system-managed stores, a 
client module in the client machine is configured to pro- 
duce user-managed stores by users for the purpose of 
the users of the client machine. For example, a user of 
a client machine may want to create a local protected 
store for securing personal files. FIG. 6B shows an ex- 
emplary folder layout 620 according to one aspect of the 
present invention. A protected store root 622, although 
not necessary, is a convenient way to include a number 
of user-managed folders 624 and system-managed 
folders 626. Each of the user-managed folders 624 is 
locally created and managed by a user. The operations 
of the user-managed stores are similar to those system- 
managed stores except that they can be accessed by 
the user without the user or the client machine being 
authenticated with the server first. While each of the sys- 
tem-managed folders 626 are created and managed by 
the system, none of the folders 626 can be accessed 
without the user and/or the client machine being authen- 
ticated first by the server. 

[0061] In addition, underthe protected store root 622, 
there is a system -man aged folder 624 that is used to 
unprotect secured files. The folder 624 may correspond 
to the store 11 2 of FIG. 1 B. One of the purposes for such 
store is to provide a mechanism to conveniently remove 
all securities embedded in secured files. FIG. 6C shows 
a flowchart of removing security process 630. At 632, 
the process 630 determines whether a secured file has 
been deposited in the store. When a file is detected in 
the store, the process 630 proceeds forward. At 634, the 
deposited file is determined whether it is a secured file 
or just a plain file. The process 630 does nothing with 
regard to a plain file. When it is determined that the de- 
posited file is secured, the process 630 goes to 636 to 
retrieve the access privilege of the user attempting (i.e., 
depositing) the file. As described above, the access priv- 
ilege of the user is determined by the system when the 
user is authenticated with the server. In the case that 
this special store is also one of the user-managed 
stores, the user's authorization is assumed to be valid. 
[0062] At 638 ; it is to determine whether the user is 
permitted to unsecure the secured file. This is usually 
done by retrieving an applicable set of access rules from - 
the secured file and comparing the rules against the ac- 
cess privilege of the user. If the user is determined not 
to have the privilege to do so, the process 630 stops 
proceeding forward and instead returning to 632. Con- 
versely, if the user is determined to have the privilege to i 
do so, the process 630 goes forward to decrypt the data 
portion at 640, starting to recover the original plain file. 
A decrypted version of the secured file, a clean or plain 



file is thus reproduced at 642. 

[0063] Regardless a designated store is system-man- 
aged or user-managed, there are needs to create sub- 
stores or child-stores under the designated store as 
5 shown in FIG. 6D : wherein a parent store 650 includes 
secured files 652 and one or more child-stores (only one 
654 is shown). A child-store can also include secured 
files 656 and a number of grand child-stores 658. Since 
the parent store 650 is associated with a pre-determined 
*o security template 651 , it is generally preferable that the 
security in the security template 655 for the child-store 
654 is defined within the security for the parent store. In 
other words, the security forthe child-stores can only be 
more restrictive than that of the parent store. 
5 [0064] FIG. 6E shows a process flowchart 660 of cre- 
ating child-stores under a parent store according to one 
embodiment of the present invention. The process 660 
is applicable to both system-managed and user-man- 
aged stores. At 662, a sub-store is created by using, for 
o example, tools commonly available in many operating 
systems. To ensure that the newly created sub-store is 
also secured, the security template for the parent store 
is retrieved at 664 and is associated with the newly cre- 
ated sub-store. In other words, the security of the sub- 
5 store is identical to that for the parent store by default. 
At 666, the security forthe sub-store is determined. Ac- 
cording to one embodiment, the security for the child- 
store is configured based on the retrieved security tem- 
plate. For example, it is permitted to take off certain 
' items. If a list of authorized users permitted to access 
secured files in the parent store includes user A and user 
B, rt is acceptable to narrow down the list to include only 
user A for the sub-store. In general, the security for the 
sub-store is more restrictive than that for the parent 
35 store. 

[0065] At 668, the determined security template for 
the sub-store is checked to see if it is in conflict with that 
for the parent store in any way. If it is found that one item 
(e.g., a rule parameter) in the security template for the 
*o sub-store conflicts with the parent store, for example, 
the security thereof is loosened compared to the parent 
store, the process 660 goes back to 666 to require a 
modification of the security template for the sub-store. 
In one specification, the parent store is created to man- 
's age secured Microsoft Word documents for marketing 
and engineering teams. A sub-store is created to man- 
age secured Microsoft Word and Powerpoint docu- 
ments or to manage secured Microsoft Word for mar- 
keting and sales teams would not be permitted. On the 
'*<> other hand, if it is found that none of the items in the 
security template for the sub-store conflicts with that for 
the parent store, the sub-store is finalized at 670 and 
subsequently associated with the security template 
therefor. As a result, all files deposited in the sub-store 
5 will be secured in accordance with the security template 
forthe sub-store. 

[0066] In an enterprise environment, changes to a se- 
curity system are quite often. When there are changes 
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(e.g., updates or revisions) pertaining to the system- 
managed stores, these changes must be timely propa- 
gated to those stores that are being affected. FIG. 7A 
shows a flowchart of delivering changes process 700 
that may be implemented or executed in a local ma- 
chine, a server or a distributed manner. 
[0067] At 702 : the process 700 awaits related policy 
changes. Commonly assigned co-pending US Patent 
Application No.: 10/186,203 entitled "Method and sys- 
tem for implementing changes to security policies in a 
distributed security system" provides descriptions of de- 
livering policy changes in a security system, which is in- 
corporated by reference. When a change pertaining to 
any of the system-managed store is received, the proc- 
ess 700 proceeds forward. First, based on the received 
change, it needs to determine how many of the system- 
managed stores are being affected by the change. For 
example, a change is received to remove an access per- 
mit previously given to a consulting team. According to 
one embodiment, each of the system -man aged stores 
is looked up to determine how many of the stores are 
set up for allowing the access from the consulting group. 
There may be one or a few such stores that are now 
affected by the change. Accordingly, respective mod- 
ules, preferably, each for one affected store, are pre- 
pared to carry out the policy change. 
[0068] At 708, these modules are released or sent out 
to the devices that host the affected stores to proceed 
with effectuating the policy change with the stores. Ac- 
cording to one embodiment, these modules are imple- 
mented as what is commonly referred to as "spiders" or 
"crawlers". Each of the spiders finds its way to the cor- 
responding store and propagates the change to the 
store. 

[0069] As described above, a security template is as- 
sociated with each store. Accordingly, the security tem- 
plate needs to be updated with the change so that all 
subsequent files being deposited are secured in accord- 
ance with the latest security template. At 71 0, a security 
template with an affected store is updated. In the case 
that there are secured files in the affected store, these 
secured files shall be updated to reflect the change such 
that the security in these files are up to date. At 712, 
each of the secured files in the affected store, if there is 
any, is updated in accordance with the latest security 
template. Typically, many changes pertain to one or 
more access policies, thus only the headers in the se- 
cured files are actually revised. 

[0070] FIG. 7B illustrates that an update patch 720 (e. 
g., carried in a spider or pushed from a central server) 
is being propagated into an affected store associated 
with a security template 722 and including a secured file 
724. The updated patch 720 can include, for example, 
a new set of access rules, a user key, or a protection 
key for a particular user or group. Preferably, a change 
in the updated patch is to replace or overwrite an affect- 
ed part. As illustrated, the security template 722 is up- 
dated to include the resulting change 723. Meanwhile 



the secured file 724 is looked up for the corresponding 
change, ft is assumed that a part 730 in the header 728 
of the secured file 724 needs updating. According to an 
exemplary structure, the secured file 724 includes an 

5 encrypted data portion 726 and an encrypted version of 
the header 728. Thus to change anything in the header 
728, a decryption and encryption process 732 for the 
header has to be carried out automatically. According to 
one embodiment, the access control module managing 

10 the store is activated to decrypt the header first and 
make the necessary changes to the header 728 and, 
finally, encrypt the header to reproduce the secured file 
736 with the resulting change 734. 
[0071] In one embodiment, the access control module 

15 is implemented as a filteroperating in operating systems 
(e.g., Microsoft Windows) such that the operations 
thereof can be made transparently to users. Additional 
descriptions of the implementation of the access control 
module to operate in operating systems can be found in 

20 U.S. Patent Application No.: 10/074,804. 

[0072] The invention is preferably implemented by 
software or a combination of hardware and software, but 
can also be implemented in hardware. The invention 
can also be embodied as computer readable code on a 

25 computer readable medium. The computer readable 
medium is any data storage device that can store data 
which can thereafter be read by a computer system. The 
computer readable medium can also be distributed over 
network-coupled computer systems so that the compu- 

30 ter readable code is stored and executed in a distributed 
fashion. 

[0073] The various embodiments, implementations 
and features of the invention noted above can be com- 
bined in various ways or used separately. Those skilled 

35 jn the art will understand from the description that the 
invention can be equally applied to or used in other var- 
ious different settings with respect to various combina- 
tions, embodiments, implementations or features pro- 
vided in the description herein. 

40 [0074] The present invention has been described in 
sufficient details with a certain degree of particularity. It 
is understood to those skilled in the art that the present 
disclosure of embodiments has been made by way of 
examples only and that numerous changes in the ar- 

4 5 rangement and combination of parts may be resorted 
without departing from the spirit and scope of the inven- 
tion as claimed. Accordingly, the scope of the present 
invention is defined by the appended claims rather than 
the foregoing description of embodiments. 

50 

Claims 

1 . A method for determining access to files via a des- 
55 ignated store, the method comprising: - 

associating a security template with the store; 
retrieving the security template when a file is 
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22 



deposited in the store; 

encrypting the file in accordance with the secu- 
rity template to produce an encrypted data por- 
tion; 

generating a header to include security infor- s 
mation from the security template: and 
integrating the header with the encrypted data 
portion to produce a secured file. 

2. A method according to Claim 1 , wherein the asso- 10 
ciating of the security template with the store in- 
cludes providing the security template to a comput- 
ing machine after one or both of the computing ma- 
chine and a user thereof are authenticated. 

15 

3. A method according to Claim 1 or 2, wherein the 
security template is managed by a server machine 
coupled to the computing machine over a network. 

4. A method according to any preceding claim, where- 20 
in the store is located in one of the computing ma- 
chine, the server machine or a separate storage de- 
vice. 

5. A method according to any preceding claim, where- 25 
in the security information in the header is added at 
least a cipher key that, once obtained, can decrypt 
the encrypted data portion. 

5. A method according to Claim 5, wherein the cipher 30 
key is encrypted and directly or indirectly protected 
by access rules. 

r . A method according to any preceding claim, where- 
in the generating of the header to include the secu- 35 
rity information from the security template compris- 
es:- 

copying the security information into the header 
from the security template; 40 
obtaining a cipher key, that, once obtained, can 
decrypt the encrypted data portion; and 
encrypting the cipher key to produce an en- 
crypted version of the cipher key. 

45 

A method according to Claim 7, wherein the en- 
crypted version of the cipher key is protected by the 
security information in the header of the secured 
file. 

50 

A method for determining access to files via a des- 
ignated store, the method comprising:- 

associating a security template with the store; 
retrieving the security template when a secured ss 
file is deposited by a user in the store, wherein 
the secured file includes a header and an en- 
crypted data portion, the header including em- 



bedded security information controlling restric- 
tive access to the encrypted data portion; 
evaluating the embedded security information 
from the header of the secured file against ac- 
cess privilege of the user to determine whether 
the user is permitted to revise the embedded 
security information of the secured file; and 
superseding the embedded security informa- 
tion with current security information from the 
security template after the user is determined 
to be permitted to revise the embedded security 
information of the secured file. 

10. A method according to Claim g, wherein the super- 
seding of the embedded security information with 
the current security information comprises:- 

preserving the embedded security information 
in a temporary place; and 
replacing the embedded security information in 
the header of the secured file with the current 
security information. 

1 1 . A method for determining access to files via a des- 
ignated store, the method comprising:- 

associating a security template with the store; 
retrieving the security template when a secured 
file is deposited by a user in the store, wherein 
the secured file includes a header and an en- 
crypted data portion, the header including em- 
bedded security information controlling restric- 
tive access to the encrypted data portion; 
evaluating the embedded security information 
from the header of the secured file against ac- 
cess privilege of the user to determine whether 
the user is permitted to revise the embedded 
security information of the secured file; and 
after the user is determined to be permitted to 
revise the embedded security information of the 
secured file, evaluating current security infor- 
mation in the template to determine whether the 
user is permitted to access files in the store; 
after the user is determined not to be permitted 
to access the files in the store, adding a special 
access policy to the security information to be 
included in the header such that the user can 
still access the secured file secured in accord- 
ance with the security template associated with 
the store. 

12. A method according to Claim 11, wherein the spe- 
cial access policy is deleted or revised after the se- 
cured file is secured again via another store with 
another security template. 

13. A method for determining access to files via a des- 
ignated store, the method comprising:- 
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associating a decryption module with the store; 
when a secured file is deposited by a user in 
the store, the secured file including a header 
and an encrypted data portion and the header 
including embedded security information con- 5 
trolling restrictive access to the encrypted data 
portion, evaluating the embedded security in- 
formation from the header of the secured file 
against access privilege of the user to deter- 
mine whether the user is permitted to unsecure 10 
the secured file; 

after the user is determined to be permitted to 
unsecure the secured file, retrieving a file key 
from the header: and 

decrypting the encrypted data portion to pro- is 
duce a plain file. 

A system for determining access to files via a des- 
ignated store, the system comprising:- 

20 

a server machine providing management to the 
store, the server accessible by a first user to 
determine access policies for the store such 
that all secured files in the store have substan- 
tially similar security, wherein the store is asso- 25 
ciated with a security template; 
at least a client machine coupled to the server 
machine over a first network, after a user of the 
client machine is authenticated by the server 
machine, the client machine communicating so 
with the server machine to activate the security 
template, if the security template is already in 
the client machine, or download the security 
template from the server, if the security tem- 
plate is not already in the client machine., and 35 
wherein unsecured files deposited by the user 
into the store are secured in accordance with 
the security template. 

A software product to be executed in a computer for 40 
determining access to files via a designated store, 
the software product comprising:- 

program code for associating a security tem- 
plate with the store; 45 
program code for retrieving the security tem- 
plate when a file is deposited in the store; 
program code for encrypting the file in accord- 
ance with the security template to produce an 
encrypted data portion; so 
program code for generating a header to in- 
clude security information from the security 
template; and 

program code for integrating the header with 
the encrypted data portion to produce a se- ss 
cured file. 



13 



1326156A2_I_> 



EP 1 326 156 A2 




14 

SDOCID: <EP _13261S6A2J_> 



EP 1 326 156 A2 




15 

BNSDOCID: <EP 1326156A2 1 > 



EP1 326 156 A2 



OQ 
U. 



C 

g 

c3 
E 

c 
^_ 

CD 

.c 

Q_ 

b 



CO 

Q_ *- 
u_ CO 

o 1/3 

>* o 
O o 

o < 
CL 



c 
o 

"co 5 
c Q 

CD 

CO r- 



o 

CO 



c 



16 

4S0OCID: <EP 1326156A2J_> 



EP 1 326 156 A2 



?xml version= M 1.(T encoding= ,, UTF-8" ?> 

ruleStatement ruleld= M OO0OOOOO00O0O0OOOOO000OO0O0OO00000O0" metaPolicyRef="metaPolicy1 M 
xmlns= n http://\vvw.pervasivesecxom/rules/PSS-xacml-01.xsd" 
xmins:xsi^'Mp://w\AW.w3.org/2001/XMLSchema-instance M 
xmins:saml="urn:oasis:names:tc:SAML:1.0:assertion" 
xmlns:ss="http://www.pervasivesec.com/rules/PSS-rules-language-01 .xsd" 
xsi:schemaLocation=''http://www.pervasivesecxorTVmles/PSS-xacrnl-01.xsd 

./xacml/PSS-xacml-01 .xsd 
urn:oasis:names:tc:SAML:1.0;assertion 

./xacm!/PSS-saml-01 .xsd 
http://www.pervasivesec.com/rules/PSS-rules-language-01.xsd 

./xacml/PSS-rules-language-01 .xsd M > 

:target> 

<subjects> 

*sam! Attribute AttributeName» ,, Group H 
AttributeNamespace="http://wvw.pervasivesec.com/rules/PSS-rules-language-01.xsd > 

<: S aml:AttributeValue><ss:Group>MKTG</ss:Gro 

</subjects> 

<resources> 

<saml:Attribute AttributeName^'DocumentName" 
AttributeNamespace= M http://www.pervasivesec.com/rules/PSS-rules-language-01.xsd > 

csaml:AttributeValue><ss:DocumentN^ 
iue></saml:Attribute> 

</resources> 

<actions> 

<saml:Action>view</saml:Action> 

<saml:Action>print</saml:Action> 

</actions> 
</target> 

<effect>permit</effect> 
<condition> 
<and> 

<ss:TimeOfDaylnRange><ss:TimeOfDayRange lo="08:0C:00" hi="1 7:00:00" 
/></ss:TirneOfDaylnRange> 

<ss*URLMatch><ss:URLPreFix> https:// w </ss:URLPrefix></ss:URLMatch> 
<ss:DatelnRange><ss:DateRange lo="1 000-01-01" hi="2002-08-03 M /></ss:DatelnRange> 

</and> 
</condttion> 
</ruleStatement> 
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